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Description 

Field of the Invention 

5 [0001 ] The present invention generally relates to electronic data processing, and more particularly, relates to method, 
computer program product and system for Improved user Interaction. 

Background of the Invention 

10 [0002] Favorites, as provided for example by conventional browsers, such as the Microsoft Internet explorer, are 
known by those skilled In the art. When a user accesses an application through a browser on a client, the user can 
use an "Add- Favorites-function to add a representation (Favorite) of the application to a "Favorites-Menu" of the brows- 
er. Later on the user can use the representation to reload the application into the browser, if the application is a stateless 
application, in other words, if the current state of the application is available on the client, the current state of the 

15 application can be saved by the browser when the user adds the corresponding representation to the "Favorites-Menu". 
When the user returns lo the application through the "Favorites-Menu", the state of the application is restored. 
[0003] World Wide Web (WWW) concepts focus on stateless scenarios, where the client knows the complete state 
of the application. For many business related applications, stateless applications show insufficient perfonnance be- 
cause large nmounts of data have lo be transmitted from the server to the client to make all state information available 

20 on the client. Fufthcr. data traffic created by stateless business applications requires high-bandwidth communication 
lines between ihc sender and the client. The "Add-Favorite" -function, as described above, does not support "Favorites" 
related to statcfui applications, that is, applications that store the state on the server, where the application is running, 
rather than on the cl cn:. 

25 Summary cl Iho Invention 

[0004] Thorofofo it is an objective of the present invention to provide methods, computer program products and 
computer sy<ii.>ms to provide client-side favorites in a browser, wherein the favorites relate to stateful applications. 
[0005] Tc mod this cbjoclive. methods according to claims 1, 5 and 8 are provided. Further embodiments of the 

30 present invention provide a computer system running computer programs to execute the methods. 

[0006] It IS an cftect of the present invention that a stateful favorite for a stateful application on a server is defined 
by a client (lor cxrimpic through a user of the client) without the need of favorite-information to be stored on the server. 
Therefore maiaqomcni of stateful favorites can be handled completely by the client without the risk of leaving obsolete 
favorile-inforrraiion on :hc server when, for example, deleting a stateful favorite on the client. 

35 [0007] It IS h tunhcr effect of the present invention that the client does not need to store a complete session-state 
with the favorite n the browser to restore the session-state on the server. Because the session-state of a stateful 
application can reach several mega bytes In size, extracting mandatory infomnation from the session-state saves band- 
width in the cicnt server CDmmunication and further saves memory for storing the favorite on the client. 
[0008] It IS a furihcr effect of the present Invention that a stateful application behaves like a stateless application 

40 when using a corresponding stateful favorite in the browser of the client. That is, when creating a stateful favorite, a 
reduced state of tnc stateful application is transmitted from the server to the client. When executing the stateful favorite 
the reduced state is transmitted to the server similar to a stateless application. 

[0009] The aspects ol the invention will be realized and attained by means of the elements and combinations par- 
ticularly pointed out in the appended claims. It Is to be understood that both, the foregoing general description and the 
45 following detailed descnption are exemplary and explanatory only and are not restrictive of the Invention as described. 

Brief Description of the Drawings 

[0010] 

50 

FIG. 1 illustrates a simplified block diagram of a computer system that can be used with an embodiment of 

the present invention; 

FIGS. 2A-2D illustrate a graphical user-interface of a stateful application session at different time points; 
FIGS. 3A-3C illustrate a client and a server when creating a stateful favorite in one embodiment of the present 
55 invention: 

FIG. 4 illustrates details of extracting a reduced state from a complete state; 

FIGS. 5A-5C illustrate the client and the server when restoring a stateful application session In one embodiment of 
the present inventiori; 
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FIG. 6 illustrates details of extending the reduced state to the connplete state; and 

FIGS. 7A-7C Illustrate simplified flow charts of methods to handle statef ul favorites according to the present inven- 
tion. 

5 Detailed Description of the Invention 

[0011] Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same 
or like parts. For convenience of explanation a list of references is provided prior to the claims. 

10 Definitions of terms, as used hereinafter: 

[0012] Client: 

client computer in a computer system. 
[001 3] server: 
IS server computer in the computer system. 
[0014] session: 

a session is an application instance running on a server for a specific user. 
[0015] session-state: 

a session-stale includes session dependent infomiation, such as identifiers of objects used by an application. The 
20 session dependent infomnation provides an environment to run an application instance of the application on a server. 
For convenience of explanation the "session -state" is referred to as "state", hereinafter. 
[0016] reduced state: 

portion of a state that allows to restore the complete state of a session. 
[0017] statef ul application: 

25 a stateful application holds its state on the server, where the corresponding application instance is running. 
[0018] stateless application: 

a stateless applk:ation does not hold its state on the server, where the corresponding application instance is running. 
The complete state of a stateless application is hold on the client side. 
[001 9] stateful favorite: 

30 a stateful favorite is a shortcut to an application, that can be used by a user to restore a state of a session on a server 
by launching the stateful favorite from the client. Stateful favorites can have a long lifetime and typically are valid even 
after a session ends. For convenience of explanation, "stateful favorites" are referred to as "favorites", hereinafter. 
Favorites can be included in the "Favorites-Menu" of a browser or made available as a shortcut on the client (e.g. via 
an icon or a specific key-sequence). 

35 [0020] serialize: 

serialize, as used hereinafter, means transfomilng data into a serialized data fonmat. 

[0021] FIG. 1 illustrates a simplified block diagram of an exemplary computer system, that implements embodiments 
of the present invention. Computer system 999 includes computer 900 and has a plurality of further computers 901 , 
902 (or 90q, with q=0...Q-1 , Q any number). 
^0 [0022] Computer 900 can be connected to further computers 901 , 902 via computer network 990. Computer 900 
comprises processor 910, memory 920, bus 930, and, optionally, Input device 940 and output device 950 (I/O devices, 
user interface 960). As illustrated, the Invention is present by computer program product 100 (GPP), program canrler 
970 and program signal 980, collectively "program". 

[0023] In respect to computer 900, computer 901/902 is sometimes referred to as "remote computer", computer 
^5 901/902 is, for example, a server, a router, a peer device or other common network node, and typically comprises many 
or all of the elements described relative to computer 900 . Hence, elements 1 00 and 91 0-980 in computer 900 collectively 
illustrate also corresponding elements lOq and 91q-98q (shown for q=0) in computers 90q. 

[0024] Computer 900 is, for example, a conventional personal computer (PC), a desktop and hand-held device, a 
multiprocessor computer, a pen computer, a microprocessor-based or programmable consumer electronics, a mini- 
50 computer, a mainframe computer, a personal mobile computing device, a mobile phone, a portable or stationary per- 
sonal computer, a palmtop computer or the like. 

[0025] Processor 910 is, for example, a central processing unit (CPU), a mk;ro-controller unit (MCU), digital signal 
processor (DSP), or the like. 

[0026] Memory 920 symbolizes elements that temporarily or permanently store data and instructions. Although mem- 
55 ory 920 is conveniently Illustrated as part of computer 900, memory function can also be implemented In network 990, 
in computers 901/902 and in processor 910 itself (e.g., cache, register), or elsewhere. Memory 920 can be a read only 
memory (ROM), a random access memory (RAM), or a memory with other access options. Memory 920 is physically 
implemented by computer-readable media, such as. for example: (a) magnetic media, such as a hard disk, a floppy 
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disk, or other magnetic disk, a tape, a cassette tape; (b) optical media, such as optical disk (CD-ROM. digital versatile 
disk - DVD); (c) semiconductor media, such as DRAM. SRAM. EPROM, EEPROM, memory stick, or by any other 
media, such as paper. 

[0027] Optionally, memory 920 is distributed across different media. Portions of memory 920 can be removable or 
5 non-removable. For reading from media and for writing in media, computer 900 uses devices well known in the art 
such as, for example, disk drives, tape drives. 

[0028] Memory 920 stores support modules such as, for example; a basic input output system (BIOS), an operating 
system (OS), a program library, a compiler, an Interpreter, and a text- processing tool. Support modules are commer- 
cially available and can be installed on computer 900 by those of skill in the art. For simplicity, these modules are not 
10 illustrated. 

[0029] CP P 1 00 comprises program instmctions and-optionally - data that cause processor 910 to execute method 
steps of the present invention. Method steps are explained with more detail below. In other words, CPP 100 defines 
the operation of computer 900 and its interaction in network system 999. For example and without the intention to be 
limiting, CPP 100 can be available as source code In any programming language, and as object code ("binary code") 
IS in a compiled fonn. Persons of skill in the art can use CPP 100 in connection with any of the above support modules 
(e.g., compiler, interpreter, operating system). 

[0030] Although CPP 100 is Illustrated as being stored in memory 920, CPP 100 can be located elsewhere. CPP 
1 00 can also be embodied In carrier 970. 

[0031] Carrier 970 is illustrated outside computer 900. For communicating CPP 100 to computer 900, carrier 970 is 

20 conveniently inserted into input device 940. Carrier 970 is implemented as any computer readable medium, such as 
a medium largely explained above (cf . memory 920). Generally, carrier 970 is an article of manufacture comprising a 
computer readable medium having computer readable program code means embodied therein for executing the meth- 
od of the present invention. Further, program signal 980 can also embody computer program 100. Signal 980 travels 
on network 990 to computer 900. 

25 [0032] Having described CPP 100, program carrier 970, and program signal 980 in connection with computer 900 
is convenient. Optionally, program carrier 971/972 (not shown) and program signal 981/982 embody computer program 
product (CPP) 101/102 to be executed by processor 911/912 (not shown) in computers 901/902, respectively. 
[0033] Input device 940 symbolizes a device that provides data and instructions for processing by computer 900. 
For example, device 940 is a keyboard, a pointing device (e.g., mouse, trackball, cursor direction keys), microphone, 

30 joystick, game pad, scanner, disk drive. Although the examples are devices with human interaction, device 940 can 
also operate without human interaction, such as. a wireless receiver (e.g., with satellite dish or terrestrial antenna), a 
sensor (e.g.. athemiometer), a counter (e.g., goods counter in a factory). Input device 940 can serve to read carrier 970. 
[0034] Output device 950 symbolizes a device that presents instructions and data that have been processed. For 
example, a monitor or a display, (cathode ray tube (CRT), flat panel display, liquid crystal display (LCD), speaker, 

35 printer, plotter, vibration alert device. Similar as above, output device 950 communicates with the user, but it can also 
communicate with further computers. 

[0035] Input device 940 and output device 950 can be combined to a single device; any device 940 and 950 can be 

provided optional. 

[0036] Bus 930 and network 990 provide logical and physical connections by conveying Instruction and data signals. 
40 While connections inside computer 900 are conveniently referred to as "bus 930", connections between computers 
900-902 are refen^ed to as "network 990". Optionally, network 990 comprises gateways being computers that specialize 
in data transmission and protocol conversion. 

[0037] Devices 940 and 950 are coupled to computer 900 by bus 930 (as illustrated) or by network 990 (optional). 
While the signals inside computer 900 are mostly electrical signals, the signals in network are electrical, magnetic, 

45 optical or wireless (radio) signals. 

[0038] Networking environments (as network 990) are commonplace in offices, enterprise-wide computer networks, 
intranets and the internet (i.e. world wide web). The physical distance between a remote computer and computer 900 
is not important. Network 990 can be a wired or a wireless network. To name a few network implementations, network 
990 Is, for example, a local area network (LAN), a wide area network (WAN), a public switched telephone network 

50 (PSTN); a Integrated Services Digital Network (ISDN), an infra-red (IR) link, a radio link, such as Universal Mobile 
Telecommunications System (UMTS), Global System for Mobile Communication (GSM), Code Division Multiple Access 
(CDMA), or satellite link. 

[0039] Transmission protocols and data formats are known, for example, as transmission control protocol/internet 
protocol (TCP/IP), hyper text transfer protocol (HTTP), secure HTTP, wireless application protocol, unique resource 
55 locator (URL), a unique resource identifier (URI), hypertext markup language HTML, extensible markup language 
(XML), extensible hypertext markup language (XHTML), wireless application markup language (WML), Standard Gen- 
eralized Markup Language (SGML) etc. 

[0040] Interfaces coupled between the elements are also well known in the art. For simplicity, interfaces are not 
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illustrated. An interface can be, for example, a serial port interface, a parallel port interface, a ganne port, a universal 
serial bus (USB) interface, an internal or external modenn, a video adapter, or a sound card. 

[0041] Computer and program are closely related. As used hereinafter, phrases, such as "the computer provides** 
and the program provides", are convenient abbreviation to express actions by a computer that is controlled by a 
5 program. 

[0042] FIGS. 2A-2D illustrate graphical user- interface 955 of a stateful application session at different time points 
TO, T1 , T2 and T3. The following scenario describes the interaction of a user with a financial application via graphical 
user-interface 955. The scenario will be used as an example of one embodiment of the present invention. The present 
invention can be implemented in alternative embodiments for other applications. Examples for other applications are 

10 applications in the field of logistics, human capital management, customer relationship management, product life cycle 
management or any other application that is used by the user in a business or administrative context. 
[0043] At TO (cf. FIG. 2A), the user gets prompted with graphical user-interface 955 (GUI). For example, the user 
interacts with computer system 999 via user-interface 960 (cf. FIG. 1) of client 900 (cf. FIG. 1). GUI 955 is presented 
to the user via output device 950 (e.g. a display device such as a monitor or a PDA display) in a conventional browser. 

15 In the example, FIG. 2A illustrates the initial screen of a financial application session (also referred to as application 
session, hereinafter) that allows the user to query the value of a stock option. The initial screen has first screen identifier 
SID-1. The financial application session is running on a server, such as server 901 (cf. FIG. 1) in computer system 
999. Server 901 stores the stale of the session, GUI 955 includes components 955-1 to 955-4. OPTION No. component 
955-1 is an entry field where the user indicates a number lhat identifies the option whose value is to be retrieved. 

^ VALUE component 955-2 is an output field where the retrieved option value is presented to the user. When the user 
starts the application session, for example by clicking on a corresponding menu entry in an application menu or on a 
corresponding shortcut or hyperlink on output device 950, components 955-1 and 955-2 are empty. This information 
is included in the state. The screen identifier SID-1 is also included in the state. SUBMIT component 955-3 and KEY 
FIGURES component 955-4 arc components are used by the user to launch requests to the application session on 
server 901. For example, components 955-3, 955-4 are implemented in GUI 955 as push-buttons, shortcuts, menu 
entries or the like. 

[0044] At T1 (cf. FIG. 2B). the user has entered a number, such as "123456**, Into OPTION No. 955-1 . The state of 
the application session now includes the value *'1 23456*' of OPTION No. component 955-1. The screen identifier is 
still SID-1 because the layout of the screen has not changed. The user then uses SUBMIT component 955-3 to trigger 

30 the retrieval of the option value. 

[0045] At T2 (cf. FIG. 20). server 901 has retrieved the option value "2,41 *', which is presented to the user via VALUE 
component 955-2. The screen that Is used to present the option value Is still the screen with first screen identifier SID- 
1 . The state of the application session now further Includes the value "2.41" of VALUE component 955-2. The user 
uses KEY FIGURES component 955-4 to launch a request for information that further specifies option No, "123456** 

35 [0046] At T3 (cf. FIG. 2D), server 901 has retrieved key figure values for the leverage ("8,1"), volatility ("1 7,2%") and 
spread (*'0,2") of the option. The key figure values are presented to the user in LEVERAGE component 955-5, VOLA- 
TILTIY component 955-6 and SPREAD component 955-7, respectively. These components were added to GUI 955 
as a result of the interaction of the user with the KEY- FIGURES component 955-4 atT2. For example, this is achieved 
by replacing the screen with having first screen identifier SID-1 with a further screen having second screen identifier 

40 SID-2. Therefore, the state at T3 further includes the additional components 955-5, 955-6, 955-7 and their key figure 
values as well as second screen identifier SID-2. In this example the user is mainly interested in the analysis of option 
no. **1 23456" because he/she is interested in buying or selling the option at the right time. Therefore, the user wants 
to add a new favorite-entry to the browser's "Favorites-Menu" so that, when executing the new favorite-entry, the 
application session as of T3 is restored and presents up-to-date values to the user. For example to achieve this, the 

45 user selects "ADD TO FAVORITES" from menu component 955-8. For example, the menu component 955-8 Is part 
of the browser In altemative embodiments, the user can select a corresponding button, shortcut or the like. Preferably, 
the user gives a name, such as "option 123456", to the new favorite-entry, which can be used later on to identify the 
new favorite-entry. 

[0047] Client 900 then creates the new favorite-entry that stores a reduced state of the application session as of T3. 

so The reduced state includes all infomnation about the application session that is needed by server 901 to restore the 
application session at a later point in time. Therefore, the new favorite-entry is a stateful favorite according to an 
embodiment of the present invention. For example, restoring the application session is triggered when the user selects 
the new favorite-entry in the "Favorites-Menu" or when the user executes a corresponding shortcut or link. 
[0048] The following figures explain further details of embodiments of the present invention with regards to the cre- 

55 ation of the stateful favorite on client 900. 

[0049] FIGS. 3A-3C illustrate client 900 and server 901 when creating stateful favorite 250 in one embodiment of 
the present invention. As described in FIG. 1 , client 900 has memory 920 and server 901 has memory 921 . Client 900 
and server 901 communicate via network 990. When a first computer (e.g. client 900) sends data (e.g. reduced state 
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210) to a second computer (e.g. server 901) in computer system 999 (cf. FIG. 1), actually a copy of the data is sent 
and the original data still exists on the first computer. For convenience of explanation, the same reference number is 
used for the original data and the sent copy. 

[0050] In the example of FIG. 3A. client 900 serves to access application session 200-S that Is running on server 
5 901 via URL 260. Application session 200-S is an instance of a statefut application. Therefore, complete state 200 of 
application session 200-S is stored in memory 921 of server 901 . Referring back to the scenarto of FIG. 2D, at T3, the 
user decides to create stateful favorite 250 (cf. FIG. 3C) on client 900. When selecting the "ADD TO FAVORITES" 
function, client 900 sends 410 request 989. Server 901 receives 510 request 981. Request 989 requests server 901 
to send reduced state 21 0 of application session 200-S to client 900. 

10 [0051] In FIG. 3B. server 901 extracts 520 reduced state 210 from complete state 220. In one embodiment of the 
present invention, extracting 520 includes the selection of relevant data of complete state 220 and the serialization of 
the relevant data. In another embodiment, complete state 220 is serialized and the selection of relevant data is per- 
formed using the serialized data of complete state 220. Details of the extracting 520 step are explained in FIG. 4. 
Server 901 then sends reduced state 21 0 to client 900. Upon having received 420 reduced state 210, reduced state 

IS 210 is available In memory 920. In other words, stateful application session 200-S behaves similar to a stateless 
application session. It is an effect of the present invention that the user does not recognize whether he/she is working 
with a stateless or stateful application. This results in low training efforts for the user. However, a stateless application 
session always makes its complete state available at client 900, whereas stateful application session 200-S makes 
reduced state 210 available, when it is requested by client 900. Reduced state 210 includes all infonmatlon that is 

20 required by server 901 to restore application session 200-S at a later point In time. 

[0052] In FIG. 3C, client 900 creates stateful favorite 250 in memory 900. For example, stateful favorite 250 can be 
created via the user selecting "ADD TO FAVORITES" or via dragging the URL 260 that corresponds to application 
session 200-S to, for example, the desktop. The URL is typically displayed in the browser Alternative embodiments 
for creating stateful favorite 250 are creating a shortcut on the desktop or using a hyperiink to access the "ADD TO 

25 FAVORITES" function. That is, stateful favorite 250 can have various visual representations (e.g. menu entry, shortcut, 
icon, hyperiink, etc.). For example, the user or computer system 999 assigns a title to stateful favorite 250 and client 
900 stores 430 reduced state 210 as a portion of stateful favorite 250. For example, stateful favorite is stored as file 
where the file name corresponds to the title of stateful favorite 250. Preferably, reduced state 210 is included in the 
file. For example, URL 260 is also included in the file. 

30 [0053] By sending reduced state 210 instead of complete state 220 to client 900, less bandwkith is required from 
the client-server communication via network 990. 

[0054] According to the Invention reduced state 21 0 is sent from sever 901 to client 900 when requested. Referring 
back to the example of FIG. 2, a stateless application session on server 901 would transfer its current state to client 
900 at each time point TO to T3. According to an embodiment of the present invention, complete state 220 of application 
35 session 200-S is stored In memory 921 of server 901 . Sending reduced state 21 0 to client 900 on request 989 saves 
further bandwidth. 

[0055] According to the invention stateful favorite 250 is administrated on client 900. That Is, when the user decides 
to delete a stateful favorite from memory 900, there is no need to notify the server, because server 901 has no knowledge 
of the stateful favorite on client 900. 

40 [0056] FIG, 4 illustrates details of extracting 520 reduced state 210 from complete state 220. 

[0057] Referring back to the example of FIG. 2D, at T3, complete state 220 includes infomnation about the text of 
each component as illustrated in section COMPONEfMT TEXT . It further Includes Infomnation about the value of each 
component as illustrated in section COMPONENT VALUE . It further includes infomnation about the screen identifier 
as illustrated in section SCREEN IDENTIFIER . Further sections illustrated by ^ can be included In complete state 220 

45 to store, for example, the current position of a cursor or of a scroll bar or any other element that specifies the appearance 
of GUI 955 at T3. 

[0058] In one embodiment of the present invention, state extractor 101-1 extracts 520 reduced state 210 from com- 
plete state 220. For example, state extractor 1 01 -1 is a portion of computer program product 101 (cf. FIG. 1 ) running 
on server 901 to execute method 500 (cf. FIG. 7). 

50 [0059] In the example of FIG. 2D, the information that Is needed from complete state 220 to restore application 
session 200-S as of T3 is the value "1 23456" of the option number 955-1 in section COMPONENT VALUE of complete 
state 220 and the screen identifier SlD-2 in section SCREEN IDENTIFIER of complete state 220. In the example, all 
texts in complete state's section COMPONENT TEXT and their corresponding display locations on the screen as well 
as the display locations of the values in section COMPONENT VALUE are defined on the screen having screen identifier 

55 SID-2. The values in section COMPONENT VALUE are refreshed automatically when restoring application session 
200-S for option number "123456". Therefore, the value "123456" of the option number 955-1 in section COMPONENT 
VALUE of complete state 220 and the screen identifier SID-2 in section SCREEN IDENTIFIER of complete state 220 
are included In the con-esponding sections of reduced state 210. Therefore, state extractor 101-1 can be considered 
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as an intelligent filter of state information. In one ennbodiment of the present invention, state extractor 1 01 -1 has infor- 
mation about the programming model of application 200 and, therefore, knows which information of a complete state 
of a specific application screen Is essential to restore the specific application session at a later point in time, in another 
embodiment, state-extractor can use the object model of application 200 or any other property of application 200 that 
5 identifies data representing essential information for restoring application session 200-S. At least all the essential 
infomiation is included in the con-esponding reduced state. 

[0060] In one embodiment of the present invention, server 901 serializes 531 reduced state 210 before sending 530 
(cf. FIG. SB) reduced state 210 to client 900. For example, serializing 531 is perfomried by seriafizer 101-2, which is 
an optional portion of computer program product 101. 
10 [0061 ] FIGS. 5A-5C illustrate client 900 and server 901 when restoring application session 200-S in one embodiment 
of the present invention. 

[0062] In FIG. 5A, the user selects and executes stateful favorite 250, for example by clicking on the corresponding 
entry in the "Favorites-Menu" of the browser on client 900 or by using one of the other representations of stateful 
favorite 250 that are described under FIG. SC. Client 900 sends URL 260 to server 901 . Server 901 the instantiates 

15 610 application session 200-S in memory 921 from stateful application 200, which is also stored in server memory 921 
in the example. Stateful application 200 can be stored in any storage device of computer system 999 (cf. FIG. 1). In 
the example, no instance (application session) of application 200 that corresponds to reduced state 210 is running on 
server 901 at the time when reduced state 21 0 is received from client 900. In case a corresponding Instance (session) 
is already running on server 901 , the instance can be replaced or a further instance can be instantiated. In one em- 

20 bodiment of the present invention, server 901 can prompt the user with a logon screen via client 900 if application 
session 200-S requires user authentication. Upon the user having logged on, server 901 continues to restore application 
session 200-S. If stateful application 200 supports single sign on functionality that is known by those skilled in the art 
the logon and authentication can be performed in the background without notifying the user. 

[0063] in FIG. 5B, server 901 receives 620 reduced state 210 from client 900. Reduced state 210 is loaded into 
25 application session 200-S. In one embodiment of the present invention reduced state 210 is received as serialized 
data. Server 901 de-serializes the serialized data. 

[0064] In FIG. 5C, server 901 extends 630 reduced state 21 0 into complete state 220 of application session 220-S. 
For example, this can be achieved by executing URL 260 with parameters that are included in reduced state 210. At 
this time, application session 200-S is fully restored on server 901 . Details of the extending 630 step are explained in 
30 FIG. 8. 

[0065] FIG. 6 illustrates details of extending 620 reduced state 210 to complete state 220. 

[0066] In the example of FIG. 2D. the infonnation that is needed from complete state 220 to restore application 
session 200-S as of T3 is the value "1 23456" of the option number 955-1 in section COMPONENT VALUE of complete 
state 220 and the screen identifier SID-2 in section SCREEN IDENTIFIER of complete state 220. 

35 [0067] In one embodiment of the present invention, state extender 101-1' extends 620 reduced state 210 into com- 
plete state 220. For example, state extender 101-1' is a portion of a further computer program product 101' (cf. FIG. 
1 ) running on server 901 to execute method 600 (cf . FIG. 7). For example, state extender 1 01 -V executes the application 
corresponding to URL 260 (cf . FIG. 5C) in application session 200-S (cf . FIG. 5C) by using the values that are included 
in reduced state 210 as input parameters for the application. In the example, the same values as of T3 (cf. FIG. 2D) 

40 are retrieved by the application and loaded into complete state 220 in the corresponding sections COMPONENT TEXT , 
COMPONENT VALUE . SCREEN IDENTIFIER an further sections^ 

[0068] In case, for example, the values for components 955-1 , 955-2, 955-6 or 955-7 have changed since TS, the 
current values can be loaded into complete state 220. 

[0069] In one embodiment of the present invention, server 901 de-serializes 615 reduced state 210 when receiving 
45 reduced state 210 from client 900 in a serialized data fomnat. For example, de-serializing 615 is performed by de- 
serializer 1 01 -2', which is an optional portion of computer program product 101'. 

[0070] FIGS. 7A-7C llluslrale simplified flow charts of methods 400. 500 and 600 to handle stateful favorites according 
to the present invention. Preferably, method 400 is executed by client 900 but can be executed by any other client in 
computer system 999 (cf. FIG. 1). For example, computer program product 100 (cf. FIG. 1) includes instructions that 

so cause processor 91 0 (cf . FIG. 1 ) of client 900 to execute the steps of method 400, Method 400 is referred to as client 
method 400 in the following description. Preferably, methods 500, 600 are executed by server 901 but can be executed 
by any other server in computer system 999. For example, computer program product 101 (cf. FIG. 1 ) includes instruc- 
tions that cause processor 911 (cf. FIG. 1) of server 901 to execute the steps of method 500. Method 500 is referred 
to as first server method 500 in the following description. For example, computer program product 101' (cf. FIG. 1) 

55 includes instructions that cause processor 911 (cf. FIG. 1) of server 901 to execute the steps of method 600. Method 
600 is referred to as second server method 600 in the following description. 

[0071] As shown in FIG. 7A, client method 400 for creating stateful favorite 250 on client 900 includes the following 
steps: 
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Sending 41 0 request 989 for reduced state 21 0 of stateful application session 200-S from client 900 to server 901 . 

Receiving 420 at client 900 reduced state 210 from server 901 . 

Storing 430 reduced state 210 as a portion of stateful favorite 250. 

Preferably, in the receiving 420 step reduced state 210 has a serialized data fonnat. 

5 

[0072] FIG. 7B shows a simplified flow chart of first server method 500 for providing reduced state 210 of stateful 
application session 200-S. wherein stateful application session 200-S has complete state 220 on server 900. First 
server method 500 includes the following steps: 

10 Receiving 51 0 at server 901 request 989 for reduced state 21 0 from client 900. 

Extracting 520 reduced state 210 from complete state 220. 
Sending 530 reduced state 21 0 to client 900. 

Preferably, server 901 sends reduced state 210 in a serialized data format. Therefore, optionally, server 901 se- 
rializes 525 reduced state 210 before sending 530. 
IS FIG. 7C shows a simplified flow chart of second server method 600 for restoring stateful application session 200-S 

on server 901 . Second server method 600 includes the following steps: 

Instantiating 610 on server 901 stateful application session 200-S that corresponds to stateful favorite 250 on 
client 900. 

20 Receiving 620 reduced state 21 0 of stateful application session 200-S on server 901 , wherein reduced state 

210 Is a portion of stateful favorite 250 on client 900. 

Extending 630 reduced state 210 to complete state 220 of stateful application session 200-S. 

[0073] In one embodiment, reduced state 210 is received by server 901 in a serialized data fonnat and optionally, 

2S server 901 de-serializes 625 reduced state 21 0 before extending 620. 

[0074] In another embodiment of the present invention, optionally, server 901 processes 615 a logon of the user to 
authenticate the user. Logon procedures to authenticate a user are known by those skilled in the art. 
[0075] The following coding section 1 provides a Java Script example of client-side coding that can be used on client 
900 (cf. FIG. 1). Coding section 1 can be a part of an HTML-page on client 900, wherein the HTML-page represents 

30 application session 200-S running on server 901. Those skilled in the art can use coding section 1 to enable client 
method 400 and server methods 500, 600. A double asterisk (**) is used to indicate the start/end of comment sections 
in coding section 1 to explain a previous portion of the coding example for those skilled in the art. 

Coding section 1 : 

35 

[0076] <STYLE>.sFavorite { BEHAVIOR: 

uri(#default#savefavorite) } </STYLE> ** declaration for using a browser feature to locally save browser 
favorite data ** 
<SCRIPT> 
40 function getReducedStateQ 
{ 

var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); xmlhttp.OpenfGET*. location.href + 

"?favorite=yes", false); xmlhttp.Send(); 
return xmlhttp. responseXML; 
45 ] getReducedStateO requests reduced state 210 in an XML fomnat from server 901 ** DOM 
[0077] function fnSaveReducedState() 
{ 

var data=getReducedState(); 
my Form . Favo riteStateControl . setAttr ibute 
so ("sReducedState*',data.xml); 
) 

*^ f nSavcRoduccdStateO loads reduced state 21 0 into the variable data and stores data as attribute "sReducedState" 
of stateful favorite 250 ("myFonn.FavoriteState Contror) ** 
[0078] function fnSubmitReducedState() 
55 { 

myForm.FavoriteStateControl.value= 
my Form . FavoriteStateControl. get Attribute 
("sReducedState"): 
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myForm.submitO; 

1 

fnSubmitReducedStateO retrieves reduced state 210 from stateful favorite 250 and sends reduced state 210 to 
server 901 to restore application session 200-S ** 
s </SCRIPT> <jnput id="FavoriteStateContror class="s Favorite" types-hidden" onload= "fnSubmitReducedStateO" on- 
save="fnSaveReducedState()"> 

** Input field (that is hidden in the example but can be visible) that restores application session 200-8 when stateful 
favorite 250 is executed (onload) and that saves reduced state 21 0 with stateful favorite 250 when, for example, storing 
stateful favorite 250 (onsave). ** 

10 



Reference numbers 


Reference 


Description 


100/1 01/1 or 


Computer program product 


200 


Stateful application 


200-S 


Stateful application session /instance 


210 


Reduced state 


220 


Complete state 


250 


Stateful favorite 


260 


Unique resource locator (URL) 


400. 500, 600 


Method 


4xx, 5xx, 6xx 


Method steps 


999 


computer network system 


900. 901 . 902 


Computers 


910, 911, 912 


Processors 


920, 921 . 922 


Memories 


940 


Input device 


950 


Output device 


955 


Graphical user interface (GUI) 


955-x 


GUI components 


960 


User interface 


970 


Program carrier (computer readable device) 


980 


Program signal 



Claims 

45 

1. A method (400) for creating a stateful favorite (250) on a client (900) comprising: 

sending (410) from the client (900) to a server (901) a request (989) for a reduced state (210) of a stateful 
application session (200>S); 

receiving (420) at the client (900) the reduced state (21 0) from the sender (901 ); and 
storing (430) the reduced state (210) as a portion of the stateful favorite (250). 

2. The method (400) of claim 1 , wherein in the receiving (420) step the reduced state (21 0) is received in a serialized 
data format. 

55 

3. The method (400) of claims 1 or 2, wherein the stateful favorite (210) has a visual representation selected from 
the group of menu entry, shortcut, icon and hyperiink. 
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4. The method (400) of claims 1 . 2 or 3, wherein the stateful favorite (250) further comprises a title and a unique 
resource locator (260) that corresponds to the stateful application session (200-S). 

5. A method t600) lor restoring a stateful application session (200>S) on a server (901 ) comprising: 

inslanliatinc; (610) on the server (901) the stateful application session (200-S) that corresponds to a stateful 
favon'.c (250) en a chcnl (900); 

rccorvinc; (620) on the server (901) a reduced state (210) of the stateful application session {200-S), wherein 

the reduced state (210) is a portion of the stateful favorite (250) on the client (900); and 

extending (630) the reduced state (210) to a complete state (220) of the stateful application session (200-S). 

6. The method (500) of claim 5. comprising: 

processing i6l5) a logon of a user. 

7. The method (500) of cUims b or 6. wherein the reduced state (210) is received in a serialized data fomnat and 
the method (600) comoriscs the further step: 

de-seriali^ing (525) of l^c reduced state (210). 

8. A method (500) for provtdng n reduced state (210) of a stateful application session (200-S), wherein the stateful 
application session (200 S) has a complete state (220) on a server (901), comprising: 

receiving (510) iii the server (901) a request (989) for the reduced state (210) from a client (900); 
extracting (520) the roducoO state (210) from the complete state (220) ; and 
sending (530) the roducod stalo (210) to the client (900). 

9. The method (500) d ruim B wherein the method (500) comprises the further step: 

serializing (525) the reduced state (210). 

10. A computer program product ( 1 00) for creating a stateful favorite (250) on a client (900). wherein the computer 
program product ( 1 00) co-npc iscs a plurality of instructions causing a processor (910) of the client (900) to execute 
any of the steps of cla m i 

11. Acomputer program product (101 ) for providing a reduced state (210) of astateful application session (200-S) 
on a server (901). wherein the computer program product (101) comprises a plurality of instructions causing a 
processor (91 1 ) of the scvo- (901 ) to execute any of the steps of claims 8 or 9. 

12. A computer program product (10V) for restoring a stateful application session (200-S) on a server (901 ), where- 
in the computer program product ( 1 01 ') comprises a plurality of instructions causing a processor (91 1 ) of the server 
(901) to execute any cf the steps of claims 5, 6 or 7. 

13. A computer program product ( 101 ) lor providing a reduced state (21 0) of a stateful application session (200-S) 
on a server (901). wherein the computer program product (101) comprises: 

a state extractor (101-1) having a plurality of instructions causing a processor (911) of the server (901) to 
extract (520) the reduced state (210) from a complete state (220) of the stateful application session (200-S), 
wherein the server (901 \ sends (530) the reduced state (210) to a client (900). 

14. The computer program product (101) of claim 13, further comprising: 

a serializer (1 01 -1 ) having « plurality of instructions causing the processor (911 ) of the server (901 ) to serialize 
(525) the reduced slaio (210) Dofore sending (530). 

15. A computer program prodiic: (101') for restoring a stateful application session (200-S) on a server (901 ), where- 
in the computer program prcduct (lOV) comprises: 
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a state extender (101-1') having a plurality of instructions causing a processor (911) of the server (901) to 
extend (630) a reduced state (21 0) of the statef ul application session (200-S) to a complete state (220) of the 
statef ul application session (200-S), wherein the server (901 ) instantiates (61 0) the statef ul application session 
(200-S) that corresponds to a statef ul favorite (250) on a client (900) and wherein the reduced state (210) is 
s a portion of the statef ul favorite (250) on the client (900). 

16. The computer program product (101*) of claim 15 further comprising: 

a de-serializer (101-2') having a plurality of Instructions causing a processor (911) of the server (901) to de- 
10 serializing (625) the reduced state (21 0) when received (620) from the client (900) . 

17. A client (900) in a computer system (999) for creating a stateful favorite (250) on the client (900); the client 
(900) running a computer program (100) for executing the following steps: 

15 sending (410) from the client (900) to a server (901) a request (989) for a reduced state (210) of a stateful 

application session (200-S); 

receiving (420) at the client (900) the reduced state (21 0) from the server (901 ); and 
sionng (430) the reduced state (210) as a portion of the stateful favorite (250). 

20 18. TUc client (900) of claim 1 7. wherein the receiving (420) step receives the reduced state (210) in a serialized 

data format 

19. The client (000) of claim 17, wherein the stateful favorite (210) has a visual representation selected from the 
group of mcru entry, shortcut, icon and hyperlink. 

25 

20. Tho ci cn: (900) of claim 1 7, wherein the stateful favorite (250) further comprises a title and a unique resource 
locator (260) thrii corresponds to the stateful application session (200-S). 

21. A sorvcr (Q01) for restoring a stateful application session (200-S); the server running a computer program 
30 (10V) for executing the following steps: 

instantiating (610) on the server (901) the stateful application session (200-S) that corresponds to a stateful 
favon:o (250) cn « client (900) ; 

rcccivinc; (620) on the server (901) a reduced state (210) of the stateful application session (200-S), wherein 
35 the reduced stale (210) is a portion of the stateful favorite (250) on the client (900); and 

extending (630) the reduced state (210) to a complete state (220) of the stateful application session (200-S) . 

23. The server i^O"* ) cf claim 21 running the computer program (10V) for executing the further step: 
40 processing i615) a logon of a user. 

24. The server (90*! ) cf claim 21 . wherein the reduced state (210) is received in a serialized data format and the 
server (901 ). when running the computer program (1 01 '), executes the further step: 

45 dc-serializing (625) of the reduced state (210). 



so 
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